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Abstract — The computational infrastructure of the 

International Space Station (ISS) is a dynamic system that 
supports multiple vehicle subsystems such as Caution and 
Warning, Electrical Power Systems and Command and Data 
Handling (C&DH), as well as scientific payloads of varying 
size and complexity. The dynamic nature of the ISS 
configuration coupled with the increased demand for 
payload support places a significant burden on the 
inherently resource constrained computational infrastructure 
of the ISS. Onboard system diagnostics applications are 
hosted on computers that are elements of the avionics 
network while ground-based diagnostic applications receive 
only a subset of available telemetry, down-linked via S- 
band communications. 

In this paper we propose a scalable, out-of-band diagnostics 
architecture for ISS systems support that uses a read-only 
connection for C&DH data acquisition, which provides a 
lower cost of deployment and maintenance (versus a higher 
criticality read/write connection). The diagnostics 
processing burden is off-loaded from the avionics network 
to elements of the on-board LAN that have a lower overall 
cost of operation and increased computational capacity. A 
superset of diagnostic data, richer in content than the 
configured telemetry, is made available to Advanced 
Diagnostic System (ADS) clients running on wireless 
handheld devices, affording the crew greater mobility for 
troubleshooting and providing improved insight into 
vehicle state. The superset of diagnostic data is made 
available to the ground in near real-time via an out-of band 
downlink, providing a high level of fidelity between vehicle 
state and test, training and operational facilities on the 
ground. 
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Introduction 

As the backbone of the ISS computational infrastructure, the 
Command and Data Handling (C&DH) system is composed 
of a number of specialized computers called 
Multiplexer/Demultiplexers (MDMs), arranged in a tiered 
hierarchy connected by MIL-STD 1553B buses. The 
MDMs were built using state-of-the-art components at 
design time that were able to withstand the stringent 
environmental requirements of prolonged space flight such 
as radiation tolerance, heat dissipation characteristics and 
low power consumption. By today’s standards, the ISS 
MDMs can be classified as resource constrained devices. 

Due to the resource constraints of the Command and 
Control (C&C) MDMs and the current space-to-ground 
communications architecture, the telemetry configured for 
downlink is only a subset of all diagnostic data available 
from the MDMs and 1553 buses in the tiered hierarchy. As 
the ISS grows in size, functionality and complexity, new 
Advanced Diagnostic Systems (ADSs) will be developed 


' U.S. Government work not protected by U.S. copyright 
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that give the crew greater insight into systems state and help 
flight controllers effectively manage ISS systems while 
minimizing or eliminating any increase in human resource 
expenditures. These ADSs will require a rich set of on- 
demand data without the intrusiveness of reconfiguring the 
telemetry tables of the C&C MDMs. 

Fault detection, isolation and recovery (FDIR) applications 
both onboard and on the ground rely on in-band data from 
the C&DH system, acquired by configuring the telemetry 
tables of the C&C MDMs through files uploaded via S- 
band communications. Existing on-board FDIR 
components, which are active C&DH elements, require a bi- 
directional (read/write) connection to the avionics system 
through a 1553 bus. The in-band, bi-directional nature of 
this connection puts the hardware and software components 
of the FDIR applications into a class of the highest 
criticality, making any expansion or upgrades to these 
components extremely expensive as well as imposing 
diagnostic constraints inherent to in-band management 
architectures. 

This paper begins by presenting an overview of the 
Command and Data Handling system, the backbone of the 
ISS avionics and computational infrastructure. A similar 
background summary of the Space-to-Ground 

Communications System is presented. This background 
discussion serves as a basis for presenting the limitations of 
the existing diagnostic data dissemination architecture. We 
close by suggesting modifications and enhancements to the 
existing architecture that could yield greater insight into 
vehicle status both onboard and on the ground. 


ISS C&DH Overview 

The U.S. on-orbit Segment (USOS) C&DH System 3 
MDMs, interconnected by MIL-STD 1553B data buses, 
collect, process and distribute both data and commands to 
other MDMs acting as Bus Controllers (BCs) and other 
computational entities known as Remote Terminals (RTs). 
Not all RTs are MDMs, e.g. some are Portable Computer 
System (PCS) terminals that host applications enabling 
crew- members to send commands to the C&C MDMs via a 
MIL-STD 1553 bus. Each bus has exactly one BC and 
some MDMs act as both BCs and RTs in the C&DH tiered 
architecture. 

The C&DH system groups the computers and associated 
data buses into three tiers called the Control Tier, Local Tier 
and User Tier. 


Tier 1 

Control Tier 


Tier 2 
Local Tier 


Tier 3 
User Tier 


CVT=Current Value Table 



•User Interface 
•Vehicle level software 


•System specific software 


•Sensor/Effector Interface 


Figure 1: Conceptual View of the C&DH Architecture. 

MDMs and PCSs are major components of the ISS C&DH 
system. Commands originate in the C&C MDMs (Tier 1) 
pass through or are intercepted by Tier 2 (e.g. the Guidance, 
Navigation and Control) MDMs, move down through Tier 
3 and then finally on to the sensors and effectors 
(temperature and pressure sensors, Remote Power 
Controllers, etc.). Conversely, telemetry from lower-tier 
devices traverses up the hierarchy to the C&C MDMs. The 
crew and flight controllers interface with the ISS systems 
through Tier 1 only 4 via the PCS platform and S-band 
communications, respectively. The Current Value Table 
(CVT) is part of each MDMs memory and its data is used 
to populate PCS displays. 

Generally, the Tier 1 MDMs are two-fault tolerant (three 
identical MDMs) and Tier 2 MDM and Tier 3 MDMs are 
one-fault tolerant (two identical MDMs). In the two-fault 
tolerant case, the active MDM is designated as hot, the 
backup is warm and the third is powered off or cold. The 
warm backup acts as an RT, processing data but not placing 
commands on the bus. In the one-fault tolerant case, one 
MDM is hot and the other is powered off 5 . 

The ISS C&DH uses a cyclic data acquisition strategy, 
processing data at three different rates: 10 Hz, 1 Hz and 0.1 
Hz, with a processing rate of 80 Hz (12.5 ms) internal to the 
MDM. These rate groups are referred to as a Major Cycle 
(10 second duration), Minor Frame (1 second duration), 
Processing Frame (100 millisecond duration) and Subframe, 
respectively. The BC broadcasts a Time Synchronization 
message at the beginning of each Processing Frame. 
MDMs that are RTs on the bus adjust their local time to 
that of the time received from the BC and compensate for 
the travel time down the bus. The different rate groups then 
share the bus through Time Division Multiplexing. 


MIL-STD I553B Protocol 


3 The Russian Onboard Complex Control System, the Russian Orbital 

Segment equivalent of the USOS C&DH System, is not addressed in this 

work. 


4 Some Tier 2 MDMs have a “pass-through” capability enabling 
commands to be sent to C&C MDMs from buses between Tiers 2 and 3. 

5 There are exceptions to this strategy, but they are not important here. 
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The MIL-STD 1553B protocol is a deterministic, 
command-and-response protocol widely used in military and 
commercial aeronautics and aerospace applications with a 
nominal data rate of 1 Mbit/s for a 16-bit architecture. A 
single Bus Controller initiates command and data transfers 
on the bus, and Remote Terminals put data on the bus only 
when instructed to do so by the BC. There can be up to 32 
RTs/BC on a bus (numbered 0 through 31), with one 
address reserved for the BC. However, the Station 
configuration allows only 3 1 RTs/BC on a bus with address 
3 1 reserved as a broadcast address. 

The 1553 protocol specifies fault tolerance of the bus and 
that fault tolerance is implemented using two separate 
channels for communication over twisted, shielded copper 
wires 6 . If an error condition is detected on one of the 
channels, communication switches over to the other. In 
addition to the fault tolerance inherent to the 1553 protocol, 
the ISS C&DH architecture provides fault tolerance by 
implementing redundant buses. If both channels on a bus 
are in failure mode, the MDM 1553 cards are configured to 
switch to the healthy bus. Hence, it takes four failed 
channels to disable bus communications. 

The PCS hardware and software, which provides the crew 
interface to the C&DH system, is configured as an RT on a 
Tier 1 or Tier 2 1553 bus and therefore is an integral part of 
the C&DH system. Because of 1553 standards and MDM 
capacity, there are limitations on the number of PCS s that 
can be connected to each bus and to a single MDM. There 
can be a maximum of five PCSs on each bus, a maximum 
of eight PCSs connected directly under the C&C MDM on 
the Control buses and a maximum of seven PCSs connected 
directly under the Payload MDM on the Payload Local 
buses [2]. These limitations must be taken into 
consideration to ensure that every PCS connection is 
recognized by the MDM. 

It is important to note that the Bus Monitor mode and RT- 
to-RT transfers, which are part of the 1553 standard, are not 
currently used by the ISS C&DH system. In Bus 
Monitoring mode, the device is not an RT, therefore it 
never has commands directed to it by a BC nor will it ever 
put data onto the bus. 


C&DH Hardware and Software 

For a variety of reasons relevant at design time, the ISS 
MDMs use an Intel 386SX microprocessor running at 32 
MHz 7 , 2 MB of EEPROM, 8 MB of RAM and certain 
MDMs have a Mass Storage Device (MSD) for data storage. 
The original MSDs had a spindle drive motor with 
read/write heads but have since been upgraded to solid-state 
components. Enhanced Space Station MDMs (ESSMDM) 
have High Rate Data Link (HRDL) cards with an optical 
interface that provide data access and retrieval to the 


6 An optical version of 1553 exists, but is not used onboard the ISS. 

7 There are two types of MDMs on-board with minor differences: a 

Space Station MDM (SSMDM) and an Enhanced Space Station MDM 

(ESSMDM), where, generally, the Tier 1 and Tier 2 MDMs are 
ESSMDMs. The hardware statistics shown are for ESSMDMs. 


associated MDMs MSD at data rates approximately 100 
times faster than a 1553 network. The 386SX has a 16-bit 
external data bus and a 32-bit internal data bus (hence a 
nominal I/O data rate of 1 Mbit/s). Each MDM host User 
Application Software (UAS), which differentiates the 
functionality of one MDM from another. For example, the 
C&C MDMs host Command and Control Software (CCS) 
while the Guidance, Navigation and Control (GN&C) 
MDMs host software specific to the GN&C system. The 
UAS loads are characteristically real-time applications that 
process data at one or more of the previously mentioned 
rates in a real-time ADA Alsys run-time environment. A 
few MDMs are mounted externally to the ISS, making them 
susceptible to impact damage from micrometeorites in 
addition to being slightly more susceptible to radiation- 
induced Single Event Upsets (SEUs). At Assembly 
Complete, there will be 44 U.S. MDMs. 

The PCS is the crew’s primary command and control 
interface to the ISS core systems. The PCS computers are 
IBM Thinkpad 760XDs with a 166 MHz Pentium 
processor; 64 MB of RAM and a 3 GB hard drive, running 
the Solaris x86 operating system. The hardware platform is 
scheduled for upgrade to the IBM Thinkpad A31p (referred 
to as the Next Generation Laptop) with flight tests expected 
sometime in 2003. These new notebook computers come 
equipped with a 1.7 GHz Mobile Pentium 4 processor, 1 
GB of RAM and a 60 GB hard drive, making them 
significantly more capable than the MDMs that control all 
of the subsystems on the Station. 

The PCS laptop has a PCMCIA card that connects to a 
1553 bus through a Portable Computer Receptacle (PCR) 8 . 
Each PCR provides power and data through the same 
connector, but only connects to one data bus. This bi- 
directional connection to the 1553 bus enables the PCS’ 
primary capabilities of control and monitoring of 
core/pay load systems and Caution and Warning (C&W) 
notification and control. 

The following table shows several operation transactions 
that take place between the MDMs and the PCS. 

Table 1: Transactions and rates between MDMs and PCSs 


Description 

Direction 

Transaction 

Rate 

Display Data Transfer 

To PCS 

10 Hz 

Standard Command 

To PCS 

1 Hz 

Command from PCS 

To C&C MDM 

1 Hz 

Data Load 

To PCS 

10 Hz 

File Dump 

To C&C MDM 

10 Hz 


Note that commands sent to and from the PCS are limited 
to one command per second. Because of the 1553 
bandwidth it takes approximately 3.5 minutes to transfer 1 
MB of data from the MDM to a single PCS 9 , e.g. a 300 


8 There will be approximately 17 PCRs at Assembly Complete. 

9 The entire bandwidth of a 16-bit 1553 architecture is 1 Mbit/s, but there 
are other RTs communicating on the same bus as the file transfer. The bus 
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MB file would take approximately 17 hours to a single 
PCS, not including uplink time. 

The PCS is susceptible to Single Event Effects (SEEs) that 
occur when a high-energy radiation particle impacts a 
component of the laptop. It is estimated that SEEs will 
occur as frequently as once every 9 hours. The effects of 
SEEs vary based on the type of event: Single Event Upsets 
(SEU) or Single Event Latch-up (SEL). An SEU is usually 
a bit-flip of non-critical memory and effects may go 
unnoticed. An SEL usually affects a critical area of memory 
and may require a power reset or system replacement and 
repair. Most SEEs are recoverable by rebooting the laptop. 
The occurrence of SEEs plays a critical role in the selection 
of hardware for both the PCS and the MDMs, both of 
which are categorized as Criticality l 10 components. 

The Station Support Computer (SSC) provides crew 
support and utilization functions such as procedure viewing, 
inventory management and word processing and is the crew 
interface to the on-board Operations Local Area Network 
(OpsLAN). The OpsLAN consists of a laptop computer 
that acts as a central file server connected to a network of 
wireless access points and SSCs. The SSCs have the same 
hardware configuration as the PCS, but have a different 
software load running on a Windows NT operating system 
(the OS will be upgraded to Windows 2000 on the Next 
Generation Laptop). The SSC and OpsLAN were 
implemented to allow operations to be moved away from 
the PCS so that it is used primarily for control of ISS 
systems. A PCS can be converted to an SSC and vice versa 
simply by swapping out the hard drive. The OpsLAN and 
SSCs have no interfaces to vehicle commanding. 


Space-to-Ground Communications 

The Communications and Tracking (C&T) system is one of 
the major systems of the ISS and is divided into five 
subsystems: the Internal Audio Subsystem (IAS), the S- 
band Subsystem (S-band), the Ultrahigh Frequency (UHF) 
Subsystem, the Video Distribution Subsystem (VDS) and 
the Ku-Band Subsystem (Ku-band). Out of these five, our 
work is mainly concerned with the S-band and Ku-band 
subsystems. 

The S-band system transmits voice, commands, telemetry 
and files between the Station and ground. The IAS 
distributes audio onboard the Station to external interfaces. 
The VDS distributes video onboard the Station and to 
external interfaces, including the Ku-band for downlink. 
The UHF Subsystem is used for Extra- Vehicular Activities 
(EVA) and proximity operations 11 , while the Ku-band 
Subsystem is used for payload data downlink and video and 
file two-way transfer. NASA is studying plans to add the 


is not dedicated to the file transfer operation. 

10 A component is generally classified as Criticality 1 if failure modes 
could result in serious injury or loss of life (flight or ground personnel), or 
loss of vehicle. 

11 Proximity operations occur when the Shuttle is approaching or 
departing the Station. 


capability to transfer commands and data between the 
ground and the USOS over Ku-band as a backup to the S- 
band. The following figure shows the command path from 
the ground to the Station via S-band. 



Figure 2: USOS Command Paths 12 

The ISS C&T system uses the NASA Tracking and Data 
Relay Satellite (TDRS) System for RF communications 
between the Station and ground. The TDRS System 
satellites are in geosynchronous orbit (approximately 36,000 
km) while the Station’s mean orbital altitude is 
approximately 370 km with a period of about 90 minutes. 
The TDRS system is a line-of-sight system where the 
minimum orbital altitude for 100% view is approximately 
1200 km. The low orbital altitude of the Station relative to 
the geosynchronous orbit of the TDRS system results in 
Loss-of-Signal (LOS) events lasting approximately 10 
minutes per orbit. The period of LOS is referred to as the 
Zone of Exclusion (ZOE). One of the major purposes of 
the previously mentioned MSD attached to certain 
ESSMDMs is to store data that cannot be downlinked 
during the ZOE. When the ISS regains TDRS signal, the 
data saved on the MSD is dumped to the ground via either 
S-band or Ku-band. 


S-band System 

The S-band System is the communication system used for 
primary Command and Control of the ISS. It transports 
commands originating from the Mission Control Center- 
Houston (MCC-H) and the Payload Operations Integration 
Complex (POIC) to the ISS and transports USOS System 
and critical telemetry from the ISS to the Tracking and Data 
Relay Satellite System (TDRSS) and ultimately to the 
MCC-H and POIC. Telemetry data can be “real-time” or 
recorded telemetry data. The S-band is also used for two- 
way audio as well as file transfer between the ground and 
the C&DH system. Files are sent by flight controllers to an 
MDM to change configurations, limits, etc. and make their 
way through to the C&DH system via the 1553 C&T 
Control Bus connected to the S-band system’s Baseband 


12 MCC-H/M = Mission Control Center-Houston/Moscow. The Service 
Module Central Computer is in the Russian Segment 
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Signal Processor, where the data is decrypted before going 
onto the bus. 

The highest data rate at which the S-band system transmits 
and receives is 192 kbps on the return link (the 
communications path from the ISS to TDRSS and then to 
MCC-H) and 72 kbps on the forward link. 


Ethernet communications adaptation. The Cisco IP 
SoftPhone™ application has been successfully deployed on 
the OpsLAN, out-of-the-box, through the OCA Router with 
only a minor modification to a TCP configuration parameter 
to deal with the latency introduced by a DOMSAT link (not 
shown in Figure 2) between MCC-H and White Sands, 
NM. 


The S-band system is a two-string system (single fault 
tolerant) with no connection between the two strings. The 
backup system uses a lower data rate of 6 Kbits/s on the 
uplink and 12 Kbits/s on the downlink, with no support for 
audio. 


Ku-band System 

The Ku-band System’s main purpose is to provide a High 
Data Rate return link (from Station to the ground) for real- 
time and recorded payload data, video (real-time and 
recorded), and ISS systems telemetry' recorded during the 
ZOE. There is also a forward link capability to support the 
two-way transfer of files and video teleconferencing in 
support of the OpsLAN. The ISS Ku-band system 
nominally sends up to 150 Mbits/s of serial data to the 
ground using up to 12 different channels. System overhead 
is about 6.8 Mbits/s, leaving about 143 Mbits/s of usable 
capacity. Up to 4 of the 12 channels can contain video 
images from the VDS. Up to 8 of the channels are reserved 
for payload data and two of the payload data channels are 
shared between transmitting recorded telemetiy and recorded 
payload data. The Ku-band forward link is at a lower data 
rate than the return link. Dumping the ZOE telemetry 
through Ku-band takes minutes as compared to hours via S- 
band. 

Although the Ku-band system provides a greater data rate 
than the S-band, it is less robust. The S-band system has 
two-strings while the Ku-band system is single-string (zero 
fault-tolerant). Furthermore, structural blockage from the 
ISS itself greatly impacts the downlink communication 
availability with only approximately 70 percent coverage per 
orbit, on average, at Assembly Complete. This greater ZOE 
for Ku-band has a negative impact on available throughput, 
but throughput is still significantly greater than that of S- 
band. 

The Ku-band system connects to the C&DH system through 
an Automated Payload Switch (APS), connected to the 
C&C MDMs via the HRDL card on the C&DH side and 
via a TAXI 13 interface to the High Rate Frame Multiplexer 
(HRFM) on the Ku-band side. The recorded ISS telemetry 
goes through the APS to the HRFM and then on to the 
ground. 

The Ku-band system connects to the OpsLAN through an 
Orbital Communication Adapter (OCA) Router, providing 
Internet Protocol (IP) network connectivity between the 
ground and the OpsLAN. The OCA Router is a card that 
slides into a laptop computer, providing full-duplex RF-to - 


13 A point-to-point optical interface with a data rate of 100 Mbps 



Figure 3: Ku-band Overview Schematic 

Data Collection and Processing 

Data is collected from sensors, effectors and firmware 
controllers and is stored in the MDMs CVT. This data is 
then passed upwards in the C&DH tiered hierarchy until it 
reaches the C&C MDM. The C&C MDM CVT contains 
the composite of data generated from all ISS systems and is 
made available to the user, regardless of the origin of the 

data. From the C&C CVT, the data is distributed to the 

crew via the PCS and to the ground through the 
Communications and Tracking (C&T) System. 

The ISS generates several times more diagnostic data than 
can be downlinked to the ground through the S-band 
communications system (the only path currently available 
for downlinking real-time telemetry). Therefore, the ground 
has to choose a subset of the data stored in the CVT to be 
downlinked as cyclic telemetry. A new configuration file 

can be uploaded to the C&C MDM to select which 

parameters are downloaded according to current needs. 
However, when ground controllers are engaged in fault 
detection, isolation and recoveiy (FDIR) efforts, deciding 
which parameters are relevant to root-cause analysis is an 
error-prone task at best and can be nearly impossible due to 
the complexity of the ISS systems. Data dumps are used to 
downlink selected areas of an MDM’s memory that are not 
included in cyclic telemetry. Ground personnel use these 
dumps to look at additional data necessary for failure 
investigation. Data dumps can only be initiated from the 
ground, since the PCS does not have the ability to 
determine what memory addresses in the MDM to dump. 
Data can only be dumped from one MDM at a time. 

The MDMs do not verify the validity of the data stored in 
the CVT, resulting in the possibility of there being stale 
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data in the CVT. There is no indication that the affected 
data in the CVT is not being updated. This is commonly 
referred to as “the stale data problem”. An example of a 
situation that results in stale data being displayed on a PCS 
is an I/O card failure, a bus failure or a sensor failure. 

The C&DH system has two types of automated FDIR 
software. The first type, called Bus FDIR, is a common set 
of software located in the memory of all MDMs that act as 
BCs. The Bus FDIR software automatically detects three 
things: channel failures, loss of bus communication with an 
RT, and loss of bus communication from the BC. Channel 
failures result in an automatic channel switchover, which 
makes the redundant channel active. If the second channel 
fails, then the bus is considered failed. The automatic 
switchover can be enabled or disabled by the crew or MCC- 
H. 

The second type of automated C&DH FDIR software is 
referred to as Remote Terminal (RT) FDIR. This type of 
FDIR handles MDM failures such as loss of communication 
or total loss of the MDM. Generally, RT FDIR is 
dependent upon the tier of the MDM (characterized by its 
redundancy). For Tier 1 and Tier 2 MDMs, the RT FDIR 
determines the type of failure and switches to a redundant 
MDM if appropriate. Due to the complex hardware/software 
redundancy of Tier 3, the Tier 3 RT FDIR typically varies 
by MDM. 

The S-band flight software provides FDIR for the S-band 
Subsystem by evaluating key status parameters from the 
elements that comprise the subsystem. When a critical 
failure is detected, S-band FDIR tells the Caution and 
Warning system to issue a Caution alarm. There are two 
flight software applications for S-band recovery: S-band 
String Recovery and S-band Extended Loss of 
Communication Recovery. 

Currently, all ISS system diagnostics are performed using 
an in-band data acquisition and analysis strategy, described 
thus far, where the critical system under diagnosis is used to 
deliver and in the case of the PCS, display, diagnostic data. 
The current Station critical systems management framework 
closely resembles that of the in-band management strategy 
of the Simple Network Management Protocol (SNMP) 
where the cyclic telemetry configured for downlink from the 
CVT is analogous to an SNMP Management Information 
Base (MIB), the PCS and ground-based diagnostic 
applications analogous to SNMP Clients and the MDM 
UAS software analogous to the SNMP Agent. Also 
analogous to the SNMP in-band management architecture is 
the fact that the network being managed (here, the combined 
1553 network and S-band link) is used to transport the 
management data. All three components: the Agent, the 
Client and the network must be functional for in-band 
management to work effectively. 

Out-of-band management requires neither a functioning 
Agent nor that the network under management be operating 
in order to work. 


Proposed Diagnostic Architecture 

The first modification we suggest is that the Ku-band 
communication system be implemented as a backup to the 
critical S-band system, enabling the downlink of cyclic 
telemetry in the event of S-band communications failure. 
Perhaps the greatest obstacle to implementing this 
modification, however, is that commanding from the 
ground would require a two-way physical connection 
onboard between the C&DH system, designed and tested to 
the standard of highest criticality, and the Ku-band system, 
designed and tested to a lower standard of criticality. This 
mismatch in design standards would have one sending 
commands to a Criticality 1 entity through a system having 
a lower criticality rating. However, with better insight into 
the state of the vehicle through Advanced Diagnostic 
Systems, the need for commanding over Ku-band could be 
minimized. For example, with enhanced insight into the 
system, the ground may be able to successfully perform a 
root cause analysis using only one data dump rather than 
several. 

Regardless of whether the Ku-band system is implemented 
as a backup for S-band, ISS Program budget considerations 
require that flight controllers do more with less, and their 
workload will only increase as the ISS nears Assembly 
Complete, fulfilling its primary role as a platform for 
scientific research. As the ISS grows in size and 
complexity, flight controllers and other ground support 
personnel would benefit from having a richer set of 
telemetry at their disposal. 

As noted above, a one-way connection already exists 
between the C&DH and Ku-band systems for downloading 
ZOE files from the MSD via the APS. A second possible 
interface exists between the C&DH and Ku-band systems 
through the OpsLAN. We suggest using this as an entry 
point for a one-way, read-only connection to the 1553 
network using an SSC platform hosting a card configured as 
a 1553 Bus Monitor. Since the 1553 protocol guarantees 
that a Bus Monitor cannot put data onto the bus, the 
connection between the Criticality 1 C&DH system and the 
lower criticality OpsLAN will not violate safety 
specifications. 

Due to the nature of the tiered hierarchy of the C&DH 
system, the vast majority of data traversing the system over 
the 1553 network can be acquired by connecting as a Bus 
Monitor to four high-level buses: 

1 . CB-CT: the Control Bus used by Communications and 
Tracking for telemetry downlink and commanding, 

2. CB-INT: the Control Bus used by MDMs controlling 
internal subsystems such as the Electrical Power 
System (EPS), Environmental Control and Life 
Support System the Thermal Control System (TCS), as 
well as some capabilities to support docking and the 
Caution and Warning System, 

3. CB-EXT: the Control Bus used by MDMs monitoring 
data on the various truss segments and controlling 
some EPS and TCS functions, and 
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4. CB-GNC: the Control Bus used by the Guidance, 
Navigation and Control MDM. 

We know that the current C&DH architecture allows for a 
maximum of eight PCSs connected directly under the C&C 
MDM on the Control Buses. Since our proposed 
connections will be Bus Monitors and not RTs that must be 
serviced by an MDM, implementing the four connections 
mentioned above will not place additional burden on the 
MDMs thereby leaving at least another four connections 
open for PCS units. 


problem”. The PUIs the user wants decommutated are 
listed in an XML configuration file, built by an external 
program that interacts with the Mission Build Facility’s 
(MBF) Standard Output (StdOut) Definition Database. 
The MBF StdOut Database defines each characteristic of all 
PUIs defined for the ISS, such as the rate group a PUI 
belongs to, the 1553 message it is contained in, the word 
offset and bit offsets into the 1553 message, it’s data type, 
and more, including instructions on unit conversion if the 
PUI is an analogue signal. Decommutators for different 
buses are differentiated only by their configuration files. 


Diagnostic Data Server Architecture 

We have implemented a prototype of our proposed system 
in the Intelligent Mobile Technologies (IMT) lab at NASA 
Ames Research Center. This prototype system, called the 
Diagnostic Data Server (DDS), was developed using 1553 
data collected from test runs at the International Space 
Station Systems Laboratory (ISIL) at Johnson Space Center. 
The ISIL is the highest fidelity test and integration facility 
available for the ISS. The Hardware/Software Integration 
(H/SI) group at ISIL collected and archived the 1553 data on 
the four Control Buses mentioned above during test runs 
and made that data available to us in the IMT lab. 

The archived 1553 files are played back using the SBS 
PASS™ product on a host computer equivalent to the SSC. 
This data source computer uses the PASS software to drive 
the archived data onto a 1553 bus, maintaining the integrity 
of the time deltas between 1553 messages, for consumption 
by a data sink host with a 1553 card configured as a Bus 
Monitor. 

There is one Bus Monitor host for each of the four Control 
Buses. Each Bus Monitor host runs two processes: 1) a 
Data Collection Engine (DCE), which is responsible for 
reading the messages from the 1553 card using the interface 
library supplied by the vendor, and, 2) a Decommutator, 
which is responsible for extracting parameters called 
Program Unique Identifiers (PUIs ) 4 from the 1553 
messages. These PUIs are derived data values consumed by 
Artificial Intelligence-based ADS applications for prediction 
of ISS systems behavior and fault detection, isolation and 
recovery. 

The PUI values produced by the four Decommutators are 
aggregated onto a single server residing on the OpsLAN 
where the data is archived and distributed to multiple clients 
using a publish/subscribe architecture. The Decommutators 
send messages containing a {time stamp, name, value} 
tuple to the server using TCP socket connections. Data 
from all three rate groups: 10 Hz, 1 Hz and 0.1 Hz, are 
decommutated and checked to see if there is a change from 
the last recorded value. Only changed data is sent to the 
server. The decommutator sends a time-out message to the 
server for a PUI if the value has not changed for some 
configurable time frame, thereby addressing the “stale data 


AH parameters associated with ISS systems have an associated 
Program Unique Identifier. 
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The Data Aggregation Server platform hosts an instance of 
the open-source, freely available JBOSS implementation of 
the Java 2 Enterprise Edition (J2EE) Specification. The Java 
Messaging Service, defined by the J2EE spec and 
implemented in JBOSS, is used for the publish/subscribe 
infrastructure and the Tomcat servlet container is used for 
servicing web clients. The Decommutators publish the PU1 
tuples to the Data Aggregation Server, and ADS clients can 
subscribe to individual PUIs or to all PUIs associated with 
a given subsystem such as C&DH, EPS, TCS or ECLSS. 

The first ADS client prototype we developed as a DDS 


JPEG image is written into a repository using the Java 
Advanced Imaging class libraries. These images of system 
state are then served out to hand-held clients connected to 
the “OpsLAN” in the IMT lab through a RangeLAN2 
wireless network, the same type of wireless network used 
onboard. The image repository design approach was chosen 
in order to off-load processing responsibilities from the 
hand-held clients in consideration of battery life. All the 
client platform has to know how to do is display a JPEG 
image since all processing is done on the server side. The 
trade-off for using this approach is increased bandwidth 
utilization across the wireless network for transporting 



Figure 4: Diagnostic Data Server Architecture Schematic 


client was an Object Model of the ISS, populated with the 
PUI values obtained by subscribing to the subsystem 
“topics” available from the Aggregation Server. Through the 
DDS, the Object Model has access to all 1553 data on the 
four Control Buses, a superset of what would be available 
via cyclic telemetry downlink. A rule-based Inference 
Engine determines high-level vehicle state by interacting 
with the Object Model, creates an image of the current 
vehicle state in memory, and writes the image out to disk as 
a JPEG image when there is a change in system state. The 


images as opposed to data values. 

The Data Aggregation Server is a part of the OpsLAN and is 
therefore connected to the ground through the OCA Router 
and the Ku-band system. The fact that the Cisco 
SoftPhone® successfully establishes a TCP/IP connection 
to the ground suggests that client ADS applications on the 
ground can subscribe to the same “topics and superset of 
data to which the onboard clients subscribe since the 
Messaging Service on the Aggregation Server is built on 
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TCP. However, the Cisco SoftPhone® adjustment to the 
TCP stack parameters only address the latency associated 
with establishing a connection. This configuration change 
does not account for what would happen to a TCP 
connection when the Station goes in and out of the ZOE. 

The PUI database is used for short-term storage of change- 
only data and could be accessed by ground-based 
applications to acquire data recorded during the ZOE. Four 
fully loaded 1553 buses produce 0.5 MB/s or approximately 
43 GB of data per day. Storing change-only data reduces 
the volume, but further work must be done to derive a 
reliable percent reduction estimate. Since the short-term data 
warehouse will likely reside on an SSC in the near-term, 
understanding the actual volume of data stored will be 
important since the Next-Generation Laptops to be used for 
SSC upgrades have 60 GB hard drives. 

A prototype data warehouse is currently under development 
in the IMT lab where ADS developers use data mining 
techniques for algorithm and application development. The 
short-term database in our prototype architecture is 
implemented using the open-source MySQL Database. The 
current release of MySQL does not support transactions , 
so we use PostgreSQL, an alternative open-source database 
that does support transactions, for the prototype data 
warehouse. 

Using tools under development in the IMT lab, ADS 
developers use the data warehouse to create and playback 
fault-scenarios through a web portal provided as an interface 
to the Integrated Vehicle Health Management (IVHM) test 
bed in the lab. The IVHM test bed is a work- in-progress 
that aggregates ISS data sources from disparate locations, 
such as test data sets from the ISIL and historic ISS 
telemetry from the Operational Data Reduction Complex 
(ODRC), providing a unified interface to multiple data 
sources for ADS model developers. 

The mobile client in our prototype architecture is hosted on 
the Compaq iPaq 3850 running the Microsoft PocketPC 
operating system, a Pocket Internet Explorer web browser, 
and the Jeode™ Java Embedded Virtual Machine from 
Insignia Solutions, Inc. The prototype ADS client receives 
updated status images of the C&DH system by interacting 
with a servlet on the Data Aggregation Server at a 
configurable polling rate. Currently, the crew’s decision 
support tools are hosted on the PCS platform, which must 
be connected to the 1553 network at fixed locations. 
Through the use of the wireless network, our prototype 
DDS architecture gives ADS clients untethered access to 
diagnostic data anywhere within range of the OpsLAN 
wireless access point. 


Summary — Diagnostic Data Server 

The diagnostic data made available to the ADS clients 
through the DDS is a superset of the C&DH cyclic 


Transactions, triggers and stored procedures are planned for later 
releases of MySQL 


telemetry, acquired without placing additional burden on the 
MDMs since the 1553 cards in the DCE/Decom host 
computers are configured as Bus Monitors, not as RTs. The 
diagnostic data is acquired and disseminated out-of-band 
from the C&DH and S-band systems, and therefore does not 
rely on the 1553 network or the S-band link to be 
functioning in order to work. In the event of failure of a 
1553 bus, the DCE processes can detect bus the failure and 
the pertinent diagnostic data is disseminated to ADS clients 
via a separate network (OpsLAN and Ku-band). The number 
of Bus Monitors available to the DDS is limited by the 
1553 protocol, but is scalable in the sense that multiple 
clients can be served without adding connections to the 
1553 network. The DDS implementation uses open-source 
software wherever possible and uses Commercial Off-The- 
Shelf (COTS) hardware. Due to the nature of its design, the 
DDS will be less expensive to flight qualify and upgrade 
than Criticality 1 Station diagnostics components. 


Future Work and Challenges 

The IMT lab is working to bring the prototype DDS up to 
flight-quality standards on a track of formal testing, 
validation and verification for deployment as a flight 
experiment to support Advanced Diagnostic and Decision 
Support Systems both onboard and on the ground at MCC- 
H. Our intention is to use the Next-Generation Laptop 
(NGL) SSC upgrade as the onboard deployment platform 
for the DDS flight experiment. NASA has specified 
Microsoft Windows2000 as the operating system for the 
SSC platform. Since the DCE/Decom processes interact 
with a real-time system, these processes posses real-time 
characteristics with deadlines to meet at the 10 Hz, 1 Hz and 
0.1 Hz data rates. It is likely that in order to be effective at 
processing all 1553 messages on a bus, the DCE/Decom 
will have to be developed as a real-time application hosted 
on a real-time operating system. Further load testing is 
required to determine the suitability of the SSC upgrade as 
a Data Aggregation Server platform for DDS. 

Using a single Data Aggregation Server in the DDS 
architecture creates a single-point of failure and does not 
easily scale 4i up” to handle additional loads introduced by 
payloads and C&DH expansion through Assembly 
Complete. The weight and size of computational 
components contributes significantly to their cost of 
deployment since they must be transported to the ISS as 
payload on the Shuttle. The group in the IMT lab has 
evaluated several different COTS rack-mounted servers 
running the Windows 2000 and Linux operating systems for 
suitability as OpsLAN server elements. Aside from 
radiation tolerance, operational characteristics such as 
physical dimensions (the server needs to fit in an ISS 
payload rack, not a typical 42U rack enclosure), power 
consumption, heat dissipation and fan noise, are important 
evaluation criteria. Even though some rack-mounted servers 
can be re-packaged to fit into a payload rack, we found that 
the power consumption, heat dissipation and noise 
characteristics made the COTS rack-mounted servers 
unsuitable for deployment onboard. Our next step is to 
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identify and evaluate some server candidates from the new 
Blade Server technology. Server blades are generally 
designed for high-density deployment using ultra-low 
voltage processors and could provide a relatively 
inexpensive way to add additional computational capacity to 
the OpsLAN, as well as add scalability and fault-tolerance 
to the DDS. Since the blades would be a part of the 
OpsLAN, and not meant to do double-duty as Criticality 1 
systems (as is the PCS/SSC hardware), they could be less 
expensively qualified to a lower-radiation tolerance than 
C&DH components. 

Another area of further study regards maintaining TCP/IP 
connectivity between the Station and ground during the 
ZOE. A group associated with NASA JPL 16 has produced 
the Space Communications Protocol Standards (SCPS), a 
suite of standard data handling protocols that specifically 
address the problems associated with IP network 
connectivity in the space environment. Of particular interest 
to our work with DDS are the SCPS-FP, SCPS-TP and 
SCPS-SC protocols, analogous to the common FTP, TCP 
and IPSEC protocols, respectively. The SCP Standards are 
being progressed toward full ISO standards through the 
work of the international Consultative Committee for Space 
Data Systems (CCSDS) 17 . Using these protocols between 
the ISS and ground could enable the use of COTS 
applications on the OpsLAN without modification for the 
ZOE, since the underlying protocol makes the discontinuity 
transparent to applications at higher layers of the ISO stack. 

The ISS OpsLAN uses Proxim RangeLAN2™ products, 
based on the OpenAir standard, for wireless connectivity. 
The OpenAir standard is used for the wireless LAN 
(WLAN) because it was found less susceptible to multipath 
effects than 802.11b in the “tin can” environment of the 
ISS. The RangeLAN2™ products are Frequency Hopping 
Spread Spectrum (FHSS) radios. Though it is known that 
the Orthogonal Frequency Division Multiplexing (OFDM) 
used in 802.11a WLANs reduces crosstalk compared to 
FHSS, it is unclear whether OFDM radio components 
would be as well behaved as the OpenAir FHSS 
components in an environment dominated by multipath 
effects. An upgrade of the RangeLAN2™ WLAN to 802.1 la 
would provide an approximately four-fold increase in 
bandwidth for the wireless portion of the OpsLAN. Further 
study is needed in this area. 

The true utility of the DDS lies in its ability to serve data 
to client applications that make the tasks of crew and 
ground personnel easier, enabling them to “do more with 
less”. Advanced Diagnostic Systems are being developed to 
give the crew and ground greater insight into an increasingly 
complex system. Prototype ADSs, initially target for use by 
flight controllers at MCC-H, are under development for the 
ISS C&DH and Electrical Power Systems by the 
Livingstone Group at Ames Research Center and^the 
Institute for the Study of Learning and Expertise (ISLE) in 


16 http://www.scDS.ora/ 

17 The ISS formats telemetry from the CVT in CCSDS packets for 
downlink over S-band as well as other data downlinked over Ku-band. 

18 ISLE is a non-profit organization dedicated to research and education 


Palo Alto, CA., respectively. Further work is needed to 
refine the underlying models of the ADS prototypes under 
development, to better understand the interactions and 
complex relationships between the ISS subsystems, to 
represent and communicate those complex interactions 
amongst ADS subsystem models and to define new ADS 
efforts to support the goals of the ISS Program. 
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Acronyms 


ADS Advanced Diagnostic System 

APS Automated Payload Switch 

BC Bus Controller 

CB Control Bus 

CCS Command and Control Software 

C&C Command and Control 

C&DH Command and Data Handling 

C&T Communications and Tracking 

CVT Current Value Table 

DDS Diagnostic Data Server 

ECLSS Environmental Control and Life Support System 

EPS Electrical Power System 

FDIR Fault Detection, Isolation and Recovery 

GNC Guidance, Navigation and Control 

HRDL High Rate Data Link 

HRFM High Rate Frame Multiplexer 

HRM High Rate Modem 

IMT Intelligent Mobile Technologies 

ISIL ISS Systems Integration Lab 

ISS International Space Station 

LOS Loss of Signal 

MBF Mission Build Facility 

MCC-H Mission Control Center — Houston 

MCC-M Mission Control Center — Moscow 

MDM Multiplexer/Demultiplexer 

MSD Mass Storage Device 

OCA Orbital Communication Adapter 

PCS Portable Computer System 

POIC Payload Operations Integration Complex 

PUI Program Unique Identifier 

RT Remote Terminal 

SCPS Space Communications Protocol Standards 

SSC Station Support Computer 

StdOut Standard Output Definition Database 

TCS Thermal Control System 

TDRSS Tracking and Data Relay Satellite System 

TRC Transmitter/Receiver Controller 

UAS User Application Software 

ZOE Zone of Exclusion 
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